I think the logic here also needs to be updated because currently dpnp returns incorrect strides compared to NumPy. Could you also add a test to cover this case?

a = dpnp.arange(10).reshape(2,5)
a_np = numpy.arange(10).reshape(2,5)

dpnp.diagonal(a, offset=5).strides
# (0. )

numpy.diagonal(a_np, offset=5).strides
# (48, )

It seems that wasn't aligned on the master as well:

a = np.arange(10).reshape(2,5)
np.diagonal(a, offset=5).strides
# Out: (1,)

Btw I will update the code to keep the same behavior as was on the master. But I wonder if there is a strict requirement on strides equality with NumPy for a 0-size array. In any case it'd be better to handle that (if needed) in the seprarte PR.

@antonwolfy Thanks for bringing this distinction. Just curious to know if dpnp/dpctl recommends any particular numpy version dependency for testing. The app I was working with failed too with the diagonal method in stacktrace.

Would the below legacy behavior be restored, only when the offsets is outside the bounds and rest of the functionality to changed to number of bytes from number of items ?

Just curious to know if dpnp/dpctl recommends any particular numpy version dependency for testing.

We are targeting to align with the latest published numpy version.

The app I was working with failed too with the diagonal method in stacktrace.

Could you please share an example of the code with failure? It might be some other issue we have to resolve.

Would the below legacy behavior be restored, only when the offsets is outside the bounds and rest of the functionality to changed to number of bytes from number of items ?

Everywhere it will be to return the number of bytes.
In case when the offsets is outside the bounds, previously dpnp returns strides end with ...,1), and now it will end with ..., 1 * a.itemsize).
The "legacy" in that use case means "different from the numpy" for returned 0-sized array.